home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / object-faq / part4 < prev    next >
Encoding:
Text File  |  1995-07-25  |  58.5 KB  |  1,497 lines

  1. Subject: Comp.Object FAQ Version 1.0.7 (10-27) Part 4/10
  2. Newsgroups: comp.object,comp.answers,news.answers
  3. From: Bob Hathaway <rjh@geodesic.com>
  4. Date: 29 Oct 1994 11:42:17 GMT
  5.  
  6. Archive-name: object-faq/part4
  7. Last-Modified: 10/27/94
  8. Version: 1.0.7
  9.  
  10. [Strachey 67]  C. Strachey.  Fundamental Concepts in programming languages.
  11.  Lecture Notes for International Summer School in Computer Programming,
  12.  Copenhagen, Aug.
  13.  
  14.   Contains original, classical definition of polymorphism.
  15.  
  16. [Stroustrup 90] Ellis, M.A., Stroustrup. The Annotated C++ Reference Manual.
  17.  Addison Wesley.
  18.  
  19.   The ARM; the original and definitive book on C++.  Serves as the ANSI
  20.   base document for C++.  Also covers C++ implementation.  It is meant as 
  21.   a reference (including for compiler writers), not as a tutorial for
  22.   beginners.  Perhaps a better ref is [Stroustrup 91].
  23.  
  24. [Stroustrup 91] Stroustrup, B.  The C++ Programming Language (2nd edition).
  25.  
  26.   Has the ARM, better reference for the use of C++ (recommended by bs).
  27.   Contains sections on object-oriented software engineering.
  28.  
  29. [Tasker 93]  Dan Tasker.  The Problem Space, Practical Techniques for
  30.   Gathering & Specifying Requirements. ISBN: 0-646-12524-9.  Avail only from
  31.   author, dant@swdev.research.otc.com.au.
  32.  
  33.   Object-oriented requirements definition.  Hypertext.  Uses Rumbaugh's OMT as
  34.   a base.  See also APPENDIX D.
  35.  
  36. [Ungar 87] D. Ungar and R.B. Smith.  The Self Papers. [Entry To Be Completed]
  37.  
  38.   The documents on Self; a delegation/prototyping language.  Also covers Self
  39.   implementation and optimization.  See also APPENDIX E, PAPERS section.
  40.  
  41. [Wasserman 90] A.I. Wasserman et al. The Object-Oriented Software Design
  42.  Notation for Software Design Representation. IEEE Computer, 23(3).
  43.  
  44.   Presents the Object-Oriented Structured Design (OOSD) OOSE methodology.
  45.   Traditional structured techniques to OO, hybrid containing structured
  46.   design and Booch.
  47.  
  48. [Wegner 87] Peter Wegner. "Dimensions of Object-Based Language Design",
  49.   Proceedings of OOPSLA '87, October 4-8 1987, SIGPLAN Notices
  50.   (Special Issue), V22, No 12, pp168-182, 1987.
  51.  
  52. [Wikstrom 87] Ake Wikstrom.  Functional Programming Using Standard ML.
  53.  Prentice Hall, ISBN 0-13-331661-0, 1987.
  54.  
  55.   ML reference.
  56.  
  57. [Wilkie 93] George Wilkie. Object-Oriented Software Engineering - The
  58.  Professional Developer's Guide. Addison Wesley.
  59.  
  60.   Covers OOSE, 11 popular analysis and design methodologies with examples,
  61.   comparisons, and analysis, information systems (OODB), and case studies.
  62.  
  63. [Winter Partners]  Winter Partners 
  64.  
  65.   A proprietary toolset (OSMOSYS) for OOA and OOD.
  66.   Winter Partners
  67.     London Office:                 Zurich Office:
  68.       West Wing, The Hop Exchange
  69.       24a Southwark Street           Florastrasse 44
  70.       London SE1 1TY                 CH-8008 Zurich
  71.       England                        Switzerland
  72.       Tel. +44-(0)71-357-7292        Tel. +41-(0)1-386-95 11
  73.       Fax. +44-(0)71-357-6650        Fax. +41-(0)1-386-95 00
  74.  
  75. [Wirfs-Brock 90] Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener.
  76.  Designing Object Oriented Software, Englewood Cliffs, NJ. Prentice Hall.
  77.  
  78.   Presents a "Responsibility Driven Design" (RDD) with "Class, Responsibility,
  79.   Collaboration" (CRC) technique, a modern and new OOA/OOD methodology.
  80.  
  81. [Yaoqing 93]  Gao Yaoqing and Yuen Chung Kwong.  A Survey of Implementations
  82.  of Parallel, Concurrent, and Distributed Smalltalk.  ACM SIGPLAN Notices.
  83.  Vol 28, No. 9, Sept 93.
  84.  
  85.   Covers implementations of Parallel, Concurrent, and Distributed Smalltalk.
  86.  
  87. [Yourdon 92]  Edward Yourdon.  Decline and Fall of the American Programmer.
  88.  YPCS.
  89.  
  90.   Excellent coverage of modern software engineering practice and world-class
  91.   software development organizations.
  92.  
  93.  
  94.  
  95. APPENDICES
  96. ==========
  97.  
  98.  
  99. APPENDIX A  VIPS
  100. ================
  101.  
  102. These are individuals whose names appear in comp.object most often. 
  103. Please send recommendations for *major* VIPS often cited or referenced.
  104.  
  105. Booch, Grady <egb@rational.com>
  106. -------------------------------
  107.  
  108. Grady Booch has been an object- based/oriented advocate for some time.  He's
  109. written books such as Software Engineering with Ada [Booch 87], Software
  110. Components with Ada [Booch 87b], and OOA/D with Applications [Booch 91, 94].
  111. His latest notations are often referred to as simply the "Booch" method or
  112. notation and he is Chief Scientist at Rational, a company providing training
  113. and automated support for the method with a tool named "Rose" (See Appendix D).
  114. The Booch method now incorporates many modern methods, including OMT, and Dr.
  115. Rumbaugh has recently joined forces with Grady at Rational.
  116.  
  117.  
  118. Cox, Brad
  119. ---------
  120.  
  121. Founder of Objective-C, which grafts the Smalltalk facilities of an
  122. Object id and a messaging mechanism onto C.  Author of [Cox 87].
  123.  
  124.  
  125. Goldberg, Adele  (Alan Kay, Dan Ingalls)
  126. ----------------------------------------
  127.  
  128. One of the founders of Smalltalk (with Alan Kay and Dan Ingalls).  Coauthor
  129. of [Goldberg 83, ??], "Smalltalk-80 The Language and its Implementation".
  130. Smalltalk was invented by a group at Xerox PARC; and a spinoff, ParcPlace, is
  131. now marketing Smalltalk environments (see APPENDIX C).
  132.  
  133.  
  134. Meyer, Bertrand <bertrand@eiffel.com>
  135. -------------------------------------
  136.  
  137. Founder of Eiffel, author of [Meyer 88].  Often posts to comp.lang.eiffel
  138. and comp.object [what a FAQ writer notices].  His company, Interactive
  139. Software Engineering, has a case tool called EiffelCase (see APPENDIX D).
  140.  
  141.  
  142. Nygaard, Krysten (and Dahl, Ole-Johan)
  143. --------------------------------------
  144.  
  145. Inventor of Simula, the first object-oriented programming language.  Also
  146. inventor of object oriented design, for which Simula-67 was considered an
  147. implementation technique.  Now B.B. Kristensen, O.L. Madsen, B. Moller-
  148. Pedersen, and K. Nygaard are working on BETA, their successor to Simula.
  149.  
  150.  
  151. Rumbaugh, Dr. James
  152. -------------------
  153.  
  154. Part of Rumbaugh, Blaha, Premerlani, Eddy and Lorenson, the authors of
  155. [Rumbaugh 91].  They all work for GE Corporate Research and Development Center
  156. in Schenectady New York (See below) and have an OOA/OOD notation/methodology
  157. called the "Object Modeling Technique" (OMT).  It is a rather formal and
  158. complete method often discussed in comp.object.  OMTool is the name of the
  159. CASE system provided by Martin Marietta which supports OMT.  See APPENDIX D.
  160.  
  161. Recently, Dr. Rumbaugh has joined forces with Chief Scientist Grady Booch at
  162. Rational: Rumbaugh@rational.com 
  163.  
  164.  
  165. Shlaer, Sally (and Mellor, Stephen J.)
  166. --------------------------------------
  167.  
  168. >Sally Shlaer            sally@projtech.com
  169. >Project Technology      Training and Consulting using Shlaer-Mellor OOA/RD
  170. >Berkeley, CA            (510) 845 1484
  171. Also: steve@projtech.com
  172.  
  173. Cofounder of the Shlaer/Mellor OOA/RD method, president of Project Technology.
  174. As shown above, occasionally posts to comp.object [what a FAQ writer notices].
  175.  
  176.  
  177. Stroustrup, Bjarne (bs@alice.att.com)
  178. -------------------------------------
  179.  
  180. Inventor of C++, a C superset, which has probably gained the most widespread
  181. use of any object-oriented language today.  Often found in comp.lang.c++ and
  182. comp.object.
  183.  
  184.  
  185.  
  186. APPENDIX B  OBJECT-ORIENTED DATABASES AND VENDORS
  187. =================================================
  188.  
  189. This is a list of available Object-Oriented databases.  Thanks go to Stewart
  190. Clamen, who's survey on schema evolution provided a good start.  Additional
  191. short entries are encouraged; please send additions to the author of the FAQ
  192. (and/or to Stewart).
  193.  
  194. The most recent copy of Stewart Clamen's summary on available databases
  195. support for schema evolution will be available indefinitely via anonymous
  196. FTP from BYRON.SP.CS.CMU.EDU:/usr/anon/OODBMS/evolution-summary.
  197.  
  198. [Kim 89] covers a few of the research systems below in depth.
  199.  
  200. Starred entries also have an entry in "APPENDIX E  ANONYMOUS FTP SITES".
  201.  
  202. See also section 3.5 for an Object Database Management Group (ODMG) reference.
  203.  
  204.  
  205. TABLE OF CONTENTS
  206.  
  207. Extended Relational Database Model
  208.  Research Systems
  209.   POSTGRES*     [marketed by Montage]
  210.   Starburst     [IBM almaden, entry NYI]
  211.  Commercial Systems
  212.   Montage       [Research System POSTGRES]
  213.  
  214. Object-Oriented Data Model
  215.  Research Systems
  216.   AVANCE
  217.   CLOSQL
  218.   ConceptBase*
  219.   COOL/COCOON
  220.   Encore*
  221.   Exodus*
  222.   Machiavelli
  223.   MOOD4-PC*
  224.   OBST/STONE*
  225.   Ode*
  226.   Oggetto
  227.   Orion [marketed as ITASCA, see Entry]
  228.   OTGen
  229.   VODAK
  230.  Commercial Systems
  231.   ArtBASE
  232.   EasyDB (Objective Systems, Sweden)
  233.   GemStone/GeODE
  234.   ITASCA
  235.   Matisse
  236.   NeoAccess
  237.   O2
  238.   Objectivity/DB
  239.   ObjectStore
  240.   Ontos [formerly VBase]
  241.   Odapter/OpenODB program (HP)
  242.   Poet
  243.   Statice
  244.   UniSQL
  245.   Versant
  246.  
  247. Other Models
  248.  Research Systems  
  249.   GRAS*
  250.   IRIS
  251.  Commercial Systems  
  252.   IDL
  253.   Kala
  254.   Pick
  255.  
  256. Interfaces
  257.  Research Systems
  258.   Penguin
  259.  Commercial Systems
  260.   AllegroStore (Franz)
  261.   Persistence
  262.   Subtlware
  263.   Synchronicity (Smalltalk)
  264.  
  265.  
  266. EXTENDED RELATIONAL DB MODEL
  267. ----------------------------
  268.  
  269. Research Systems
  270. ________________
  271.  
  272.  
  273. > POSTGRES (Berkeley)
  274.  
  275. POSTGRES is an extended-relational database manager that supports
  276. inheritance, user-defined types, functions, and operators, ad-hoc
  277. queries, time travel, a rules system, tertiary storage devices,
  278. and very large typed objects, among other things.  POSTGRES speaks
  279. postquel, a derivative of the quel query language originally
  280. designed at berkeley for the ingres database system.  User functions
  281. may be written in C or in postquel.  C functions will be dynamically
  282. loaded into the database server on demand, and either kind of function
  283. may be executed from the query language.
  284.  
  285. POSTGRES and the papers that describe it are available free of charge
  286. from toe.CS.Berkeley.EDU (128.32.149.117) in directory pub/postgres.
  287. The code is stored in a directory named after the latest release; at
  288. the time of this writing, that directory is postgres-v4r1.  The list
  289. of officially-supported ports is short (decstations running ultrix 4.x
  290. and sparcstations).  Unofficially, many more are supported -- people
  291. elsewhere have done the ports and distribute their versions of the
  292. code.  The list of unofficial ports is available in pub/postgres as
  293. file UNOFFICIAL-PORT-LIST.
  294.  
  295. On Type Evolution:
  296. You ask explicitly about type evolution.  We support schema
  297. modification on all classes, including user classes.  This means that
  298. you can add attributes (instance slots) and methods at any time.
  299. Further, since postgres is a shared database system, such changes are
  300. instantly visible to any other user of the class.
  301.  
  302. The language syntax supports attribute deletion, but the system won't
  303. do it yet.  Since all data is persistent, removing attributes from a
  304. class requires some work -- you need to either get rid of or ignore
  305. all the values you've already stored.
  306.  
  307. Contact:
  308. Paul Aoki <aoki@cs.berkeley.edu>
  309.  
  310. The postgres code from uc berkeley is being commercialized by
  311. Miro Systems, Inc.        [This seems to have been updated to Montage]
  312.  
  313. Contact:
  314.   paula hawthorn (paula@miro.com) 
  315.   dave segleau (dave@miro.com)
  316.  
  317.  
  318. Commercial Systems
  319. ------------------
  320.  
  321. > Montage (ORDBMS) [Research System POSTGRES]
  322.  
  323. From: markh@montage.com (Mark Helfen)
  324. Subject: Montage Database - brief product announcement
  325. Followup-To: sales@montage.com 
  326. Organization: Montage Software, Inc.
  327. Date: Wed, 10 Nov 1993 23:05:03 GMT
  328.  
  329. The Montage object-relational database management system 
  330. (ORDBMS) is now available from Montage Software, Inc. 
  331.  
  332. The Montage object-relational database management system 
  333. includes the Montage Server(tm) database engine, the Montage 
  334. Viewer(tm) -- a new visualization tool that simplifies queries of 
  335. complex data -- and Montage DataBlades(tm), specialized modules 
  336. that extend the capabilities of the database for specific applications.  
  337. Montage represents the commercialization of the seven-year 
  338. POSTGRES research project.   
  339.  
  340. The Montage Server extends the relational database model through 
  341. its ability to handle complex information, and the inclusion of object-
  342. oriented facilities and capabilities.  It uses the familiar relational row-
  343. column metaphor for all data, so that text, numbers and complex data 
  344. are all viewed, managed, manipulated and queried the same way.   
  345. The relational metaphor is extended to allow data of any size and 
  346. complexity to be stored and accessed in the way that is most 
  347. effective.   SQL, used to access and manage data, is extended with 
  348. SQL3-based capabilities to allow the definition of user data types and 
  349. functions.
  350.  
  351. The Montage Viewer uses visualization technology to organize 
  352. information in visual terms -- by location, shape, color and intensity, 
  353. for example.  Similar to a "flight simulator," the Montage Viewer allows 
  354. the user to visually navigate through data, refining each step by 
  355. "panning" and "zooming" with a mouse.  
  356.  
  357. A DataBlade is a combination of data types and functions that are 
  358. designed to support a specific application.   Text, Spatial, and Image 
  359. are the first of many DataBlades that will comprise a full-range of 
  360. industry-specific products created by Montage, third parties and 
  361. users based upon their own expertise.    
  362.  
  363. o     The Text DataBlade expands the database's functionality by 
  364. adding new data types and functions that manage text and document 
  365. libraries, as well as a providing a new access method (Doc-Tree) 
  366. which provides exceptional search performance for text.  
  367.  
  368. o     The Image DataBlade supports image conversion, storage, 
  369. manipulation, enhancement and management of more than 50 image 
  370. formats, and performs automatic conversion of formats at the user's 
  371. discretion.  
  372.  
  373. o     Points, lines, polygons and their spatial relationships are now 
  374. supported in the relational model with the Spatial DataBlade.  The 
  375. DataBlade defines nine basic spatial types and makes over 200 SQL 
  376. functions available for use on spatial data, as well as supports the 
  377. R-Tree access method for high speed navigation of spatial data.    
  378.  
  379. Montage Software was co-founded by Gary Morgenthaler of 
  380. Morgenthaler Ventures and Dr. Michael Stonebraker of the University 
  381. of California, Berkeley, .  Morgenthaler is Montage Software's 
  382. chairman of the board and Stonebraker serves as the company's 
  383. chief technology officer.    Morgenthaler and Stonebraker co-
  384. founded Ingres Corporation (then called Relational Technology, 
  385. Inc.), in 1980.    
  386.  
  387. FOR ADDITIONAL INFORMATION:
  388.  
  389. Montage Software Inc. can be contacted at:
  390.  
  391. email:                        sales@montage.com
  392. phone:                        (510) 652-8000
  393. fax:                          (510) 652-9688
  394.  
  395. Mailing Address:
  396.  
  397. Montage Software, Inc.
  398. 2000 Powell Street, Suite 1405
  399. Emeryville, CA  94608
  400.  
  401. OO DATA MODEL
  402. -------------
  403.  
  404. Research Systems
  405. ________________
  406.  
  407. > AVANCE (SYSLAB)
  408.  
  409. An object-oriented, distributed database programming language.  Its
  410. most interesting feature is the presence of system-level version
  411. control, which is used to support schema evolution, system-level
  412. versioning (as a way of improving concurrency), and objects with their
  413. own notion of history.  System consists of programming language (PAL)
  414. and distributed persistent object manager. 
  415.  
  416. REFERENCES: 
  417.         Anders Bjornerstedt and Stefan Britts. "AVANCE: An
  418.         Object Management System".  Proceedings of OOPSLA88.
  419.  
  420.  
  421.  
  422. > CLOSQL (University of Lancaster)
  423.  
  424. Status:-
  425. CLOSQL is a research prototype OODB designed primarily for prototyping 
  426. various schema evolution and view mechanisms based on class versioning.
  427. The system is built using CommonLISP. It would really only be of interest
  428. to other parties as a research tool.
  429.  
  430. Requirements:-
  431. Common LISP including CLOS standard. The Graphical user interface requires
  432. the Harlequin LispWorks Tool-kit. The system was built on a Sun4 and
  433. has not been tested on any other platform.
  434.  
  435. Features:-
  436. As a prototype, CLOSQL is not robust enough to sell. The system is single
  437. user and does not properly support persistence - that is, the data has to
  438. be loaded and saved explicitly. The query language is quite good 
  439. making good use of the functional nature of the environment. 
  440. Methods (LISP and query language only), class versioning and
  441. multiple inheritance are all supported in the data model. Type checking
  442. information is held in the database, but is NOT enforced at present. The
  443. GUI is notable for its support for schema evolution, but otherwise rather
  444. ordinary.
  445.  
  446. Availability:-
  447. Probably freely available, but as the project was part funded by an
  448. industrial partner, some consultation with them would be necessary before
  449. the system could be released.
  450.  
  451. References:-
  452. [1]  Monk, S. R. and I. Sommerville, "A Model for Versioning of Classes 
  453. in Object-Oriented Databases", Proceedings of BNCOD 10, Aberdeen. 
  454. pp.42-58. 1992.
  455.  
  456. [2]  Monk, S. "The CLOSQL Query Language". Technical report No. SE-91-15. 
  457. Computing Dept, Lancaster University, Lancaster, LA1 4YR, UK. 1991.
  458.  
  459. [3]  Monk, S., "A Model For Schema Evolution In Object-Oriented Database 
  460. Systems", PhD thesis, Dept of Computing, Lancaster University, Lancaster
  461. LA1 4YR, UK. 1992.
  462.  
  463. On Schema evolution (from original survey):
  464. CLOSQL implements a class versioning scheme (like ENCORE), but employs a
  465. conversion adaptation strategy.  Instances are converted when there is a
  466. version conflict, but unlike ORION and GemStone, CLOSQL can convert instances
  467. to older versions of the class if necessary.
  468.  
  469.         Aberdeen, Scotland. July, 1992.
  470.  
  471. Contacts;
  472. Simon Monk:      srm@computing.lancaster.ac.uk
  473. Ian Sommerville: is@computing.lancaster.ac.uk 
  474.  
  475.  
  476. > ConceptBase - A Deductive Object Manager for Meta Data Bases
  477.  
  478. ConceptBase is a multi-user deductive object manager mainly 
  479. intended for conceptual modeling and the coordination of design 
  480. environments. The system implements a dialect of Telos which 
  481. amalgamates properties of deductive and object-oriented languages. 
  482.  
  483. Key features are 
  484.  
  485.    hybrid representation with frame-like objects, 
  486.    semantic nets and logical specifications 
  487.  
  488.    unlimited extensibility by metaclass 
  489.    hierarchies (useful for IRDS, schema evolution etc.) 
  490.  
  491.    deductive rules & integrity constraints 
  492.  
  493.    queries as classes with membership constraints 
  494.  
  495.    persistent object management with the ability to interrogate 
  496.    past states of the database 
  497.  
  498. ConceptBase follows a client-server architecture. Client programs 
  499. can connect to the ConceptBase server and exchange data via 
  500. interprocess communication. The X11-based ConceptBase user 
  501. interface offers a palette of graphical, tabular and textual tools 
  502. for editing and browsing the object base. The ConceptBase 
  503. programming interface allows the users to create their own 
  504. client programs in C or Prolog. 
  505.  
  506. The system can be obtained for free from ftp.informatik.rwth-aachen.de in 
  507.       /pub/CB/CB_3.2.4 (released 26-Apr-1994 for Sun/SPARC, SunOS 4.1.3) 
  508.       /pub/CB/CB_3.3 (released 26-Apr-1994 for Sun/SPARC, Solaris 2.3) 
  509. Both versions are functionally equivalent. They only differ in the 
  510. operating system platform.Please read file /pub/CB/doc/InstallationGuide 
  511. (resp. /pub/CB/doc/InstallationGuide_3.2.4) before downloading the software. 
  512. For running the ftp version you must ask for a key by email.
  513.  
  514. Contact
  515. ConceptBase-Team
  516. RWTH Aachen - Informatik V
  517. D-52056 Aachen - Germany
  518.  
  519. Tel./Fax: +49-241 80 21 501 / +49-241-8888321
  520. email: CB@picasso.informatik.rwth-aachen.de 
  521. href="http://www.informatik.rwth-aachen.de/I5/CBdoc/cbflyer.html"
  522.  
  523.  
  524. > COOL/COCOON (Ulm Universitaet)
  525.  
  526. The COCOON project was intended to extend the concepts and the
  527. architecture of relational database management systems (DBMSs) beyond
  528. nested relational to object-oriented ones. Based upon the nested
  529. relational DBMS kernel DASDBS, we have built a prototype implementation
  530. of the COCOON model. Key characteristics of COCOON are: generic,
  531. set-oriented query and update operators similar to relational algebra
  532. and SQL updates, respectively; object-preserving semantics of query
  533. operators, which allows for the definition of updatable views; a
  534. separation of the two aspects of programming language "classes": type
  535. vs. collection; predicative description of collections, similar to
  536. "defined concepts" in KL-One--like knowledge representation
  537. languages; automatic classification of objects and views (positioning
  538. in the class hierarchy); physical clustering of subobjects via the use
  539. of nested relations as the internal storage structures; support for the
  540. optimization of both, the physical DB design and query transformation,
  541. by corresponding optimizers.
  542.  
  543. Project goals are:
  544.  
  545. - to develop a general formal framework for investigations of all
  546.   kinds of schema changes in object-oriented database systems
  547.   (including schema design, schema modification, schema tailoring, and
  548.   schema integration);
  549. - to find implementation techniques for evolving database schemas,
  550.   such that changes on the logical level propagate automatically to
  551.   adaptations of the physical level (without the need to modify all
  552.   instances, if possible).
  553.  
  554. In their current paper [see below], schema evolution is used as
  555. example of a general framework for change in OODBs, supporting change
  556. on three levels of database objects: data objects, schema objects, and
  557. meta-schema objects.
  558.  
  559. Contact: Markus Tresch <tresch@informatik.uni-ulm.de>
  560.  
  561.  
  562. REFERENCES:
  563.         M. Tresch and M.H. Scholl. "Meta Object Management
  564.         and its Application to Database Evolution."  In
  565.         _Proceedings of the Eleventh International
  566.         Conference on the Entity-Relationship Approach",
  567.         Karlsruhe, Germany, Oct 1992.  Springer Verlag (to
  568.         appear).
  569.  
  570.  
  571.  
  572. > Encore (Brown University)
  573. email:bpe@browncs.brown.edu
  574.  
  575. Encore is an object-oriented database system targeted at large scale
  576. software engineering applications which are involved in data modeling.
  577. It was developed at Brown University in the late 1980s.  It is notable
  578. for its special support for long-lived (ie. cooperative) transactions,
  579. popular in design applications, and its support for class versioning.
  580. Objects are never converted, rather, classes are versioned, and the
  581. user can specify filters to make old-style instances appear as new
  582. instances to new applications (and vice versa).
  583.  
  584.  
  585. References/Additional Information:
  586.  
  587.  [] Mary F. Fernandez. OBSERVER: A storage system
  588.     object-oriented applications. Technical Report CS-90-27,
  589.     Brown University, Providence, RI, 1990.
  590.  
  591.  [] Mark F. Hornick and Stanley B. Zdonik. A shared, segmented
  592.     memory system for an object-oriented database. ACM
  593.     Transactions on Office Information Systems, 5(1):70--95,
  594.     January 1987.
  595.  
  596.  [] Andrea H. Skarra and Stanley B. Zdonik. Type evolution in an
  597.     object-oriented database. In Research Directions in
  598.     Object-Oriented Programming, MIT Press Series in Computer
  599.     Systems, pages 393--415. MIT Press, Cambridge, MA, 1987. An
  600.     early version of this paper appears in the OOPSLA '86
  601.     proceedings.
  602.  
  603.  [] Andrea H. Skarra and Stanley B. Zdonik. Concurrency control
  604.     for cooperating transactions in an object-oriented database.
  605.     In Won. Kim and Frederick H. Lochovsky, editors,
  606.     Object-Oriented Concepts, Databases and Applications.
  607.     Addison-Wesley, Reading, MA, 1989.
  608.  
  609. FTP: Complete source can be found in wilma.cs.brown.edu/pub/encore.tar.Z
  610. See also APPENDIX E.
  611.  
  612.  
  613. > Exodus (University of Wisconsin)
  614.  
  615. EXODUS is a DBMS from the University of Wisconsin.  An overview,
  616. excerpted from the abstract of [CDG+90] reads:
  617.  
  618.     EXODUS,   an   extensible database    system  project that is
  619.     addressing  data management problems  posed  by  a variety of
  620.     challenging new applications.  The  goal of the project is to
  621.     facilitate   the   fast    development of   high-performance,
  622.     application-specific  database  systems.     EXODUS  provides
  623.     certain  kernel facilities,   including  a versatile  storage
  624.     manager.  In addition, it provides an architectural framework
  625.     for building  application-specific database systems; powerful
  626.     tools   to  help  automate the  generation   of such systems,
  627.     including  a   rule-based query optimizer generator    and  a
  628.     persistent  programming  language;  and libraries  of generic
  629.     software components (e.g., access methods) that are likely to
  630.     be useful for many application domains.
  631.  
  632. The programming language is called E, an extension of C++. [RC89]
  633.  
  634. REFERENCES:
  635. (see "ftp.cs.wisc.edu:exodus/bibliography" for a complete list)
  636.  
  637. [CDG+90] Michael J. Carey, David J. DeWitt, Goetz Graefe,
  638.          David M. Haight, Joel E. Richardson, Daniel T. Schuh,
  639.          Eugene J. Skekita, and Scott L. Vandenberg. The EXODUS
  640.          extensible DBMS project:  An overview. In Stanley B.
  641.          Zdonik and David Maier, editors, Readings in
  642.          Object-Oriented Database Systems, Data Management
  643.          Series. Morgan Kaufmann, San Mateo, CA, 1990. Also
  644.          available as WISC-CS-TR 808.
  645.  
  646. [CDRS89] Michael J. Carey, David J. DeWitt, Joel E. Richardson,
  647.          and Eugene J. Skekita. Storage management for objects
  648.          in EXODUS. In Won. Kim and Frederick H. Lochovsky,
  649.          editors, Object-Oriented Concepts, Databases and
  650.          Applications, chapter 14. Addison-Wesley, Reading, MA,
  651.          1989. After Carey et al. Object and File Management in
  652.          the EXODUS Database System, Proceedings of the Twelveth
  653.          International Conference on Very Large Data Bases,
  654.          1986.
  655.  
  656. [GD87]   G. Graefe and D. DeWitt. The EXODUS optimizer
  657.          generator. In U. Dayal and I. Traiger, editors,
  658.          Proceedings of the SIGMOD International Conference on
  659.          Management of Data, San Francisco, CA, May 1987.
  660.  
  661. [RC89]   Joel E. Richardson and Michael J. Carey. Persistence in
  662.          the E language:  Issues and implementation. Software --
  663.          Practice and Experience, 19(12):1115--1150, December
  664.          1989.
  665.  
  666.  
  667. FTP: source code, documentation and a complete bibliography can be
  668.      found at ftp.cs.wisc.edu:exodus/
  669.  
  670. See also APPENDIX E.
  671.  
  672.  
  673. On Schema Evolution (from original survey):
  674. No solution for the problem of schema evolution is provided.
  675. Emulation is rejected by the authors, who claim that the addition of a
  676. layer between the EXODUS Storage Manager and the E program would
  677. seriously reduce efficiency.  Automatic conversion, whether lazy or
  678. eager, is also rejected, as it does not mesh well with the C++ data
  679. layout.  To implement immediate references to other classes and
  680. structures, C++ embeds class and structure instances within its
  681. referent.  The resulting change in the size of the object might
  682. invalidate remote pointer references.
  683.  
  684.         Joel E.  Richardson and Michael J.  Carey.  "Persistence
  685.         in the E language: Issues and Implementation."  Appeared
  686.         in "Software -- Practice and Experience",
  687.         19(12):1115-1150, December 1989.
  688.  
  689.  
  690. > Machiavelli (University of Pennsylvania)
  691.  
  692. Machiavelli is a statically-typed programming language developed
  693. at the University of Pennsylvania. Its most outstanding innovation 
  694. is the use of conditional typing scheme in its type inference system. 
  695. It does not address type evolution.
  696.  
  697. [communication with limsoon@saul.cis.upenn.edu]
  698.  
  699. [Note: Machiavelli is included in this summary because it
  700.        previously incorporated persistence in its data model.]
  701.  
  702.  
  703.  
  704. > MOOD4-PC: Material's/Miniature Object-Oriented Database Prototype for
  705.              NEC/IBM-PC
  706.  
  707. is an object-oriented database system(OODBS) program developed in the
  708. course of our research project MOOD. The aim of the project MOOD is to
  709. develop a material database system to handle raw material data which
  710. are produced and accumulated in materials research and referred to by
  711. material experts when they face scientific or engineering problems
  712. where the expected behavior of particular materials in particular
  713. environments are crucial importance. We all know that the conventional
  714. database systems do not fulfill this requirement, though they serves
  715. well for bibliographic databases or fact databases which deals with
  716. the standard properties of standard materials.
  717.  
  718. MOOD4-PC is written in Arity/Prolog and available in source and
  719. executable form via anonymous ftp from:
  720.  
  721.    ~/pub/mood/mood4
  722.    at mood.mech.tohoku.ac.jp [130.34.88.61]
  723.    
  724.     ~/pub/database/mood
  725.     at ftp.uu.net [192.48.96.9]
  726.  
  727.     ~/pub/computing/databases/mood
  728.     at src.doc.ic.ac.uk [146.169.2.1]
  729.  
  730. Although it is true enough to say that MOOD4 is a general purpose
  731. OODBS, it may be appropriate to point out that MOOD4 is significantly
  732. different from what is generally meant by the term, the
  733. Object-Oriented Database System.
  734.  
  735. That is, OODBSs, in general, consist of two parts:
  736.  
  737.    (1) Disk storage manager
  738.    (2) Database language to define and manipulate data objects to
  739.        be stored to and retrieved from the disk.
  740.  
  741. The database language of OODBS is akin to the object-oriented
  742. programming language such as Smalltalk or C++. You can enjoy the full
  743. versatility of these general purpose programming language in writing
  744. application programs with the database language.
  745.  
  746. As apparent from these, OODBSs, in general, are for programmers who
  747. write application programs which serve end users' needs. MOOD, on the
  748. other hands, is not; it is for end users. It is provided with a user
  749. interface named the object editor or OE in short. With OE, we can;
  750.  
  751.   (1) Edit class definition objects and save them. This replaces the
  752.       data definition language.
  753.  
  754.   (2) Edit data objects and save them.
  755.  
  756.   (3) Create query objects, let the system select data objects which
  757.       match the queries, and browse them.
  758.  
  759. In the other words, we can do everything necessary to manage and use
  760. database with OE. MOOD, therefore, needs no programming language and,
  761. in fact, has none. In this regard, MOOD may better be categorized to
  762. the OODBS application.
  763.  
  764. The architecture of MOOD as such is the consequence of the nature of
  765. information to be dealt with in material database. If we describe the
  766. nature with a single word, "variety" will be the one most appropriate. 
  767. No fixed data structure can handle a handful of material data because
  768. their contents differ from one to another. The feature of OODBS
  769. relevant here is not the intimacy with programming languages but the
  770. flexibility of data structure which allows us to construct data
  771. objects with a variety of structures which match the variety in the
  772. information to be dealt with. Upon inputting and retrieving data
  773. objects, end users are forced to face this variety in data structure
  774. since significant information is born in the structures of individual
  775. representations.
  776.  
  777. Yet, we say that MOOD is a general purpose OODBS. This is not in the
  778. sense that we can develop application programs on it, but in the
  779. sense that it generally supports the essential capabilities of OODBS;
  780.  
  781.   (1) The abstract data type.
  782.  
  783.   (2) The nesting of structured data objects.
  784.  
  785.   (3) The class hierarchy.
  786.  
  787.   (4) The inheritance of attributes along the hierarchy.
  788.  
  789.   (5) Matching between objects along their structures with the
  790.       knowledge of the class hierarchy.
  791.  
  792. For additional features of MOOD4, please consult its manual available
  793. with the program. Although they are biased to the processing of
  794. material data (or, more generally, scientific and technical data),
  795. MOOD with these capabilities can be used in any application domain at
  796. least by the stage where you are to examine how well the pieces of
  797. information of interest are represented in OODBS and how well specific
  798. items of interest are discriminated out from the database as such.
  799.  
  800. Questions and suggestions on this software which are ever welcome
  801. indeed may be addressed to;
  802.  
  803.      Noboru Ono                                             
  804.      Dept. of Machine Intelligence and Systems Engineering, 
  805.      Faculty of Engineering, Tohoku University.            
  806.      Tel:++22-216-8111,
  807.      Fax:++22-216-8156,
  808.      E-mail:ono@mood.mech.tohoku.ac.jp
  809.  
  810.  
  811.  
  812. > OBST/STONE (Forschungszentrum Informatik [FZI], Karlsruhe, Germany)
  813.  
  814. OBST3-4 is now available at ftp.fzi.de under /pub/OBST/OBST3-4.
  815. (Please do not confuse this new release with the older OBST3-3.4).
  816.  
  817. Experienced users will notice that we've changed the structure of
  818. our ftp directory tree somewhat: compressed and gzip'ed files are
  819. now cleanly separated. By sending
  820.     echo 'info ftp_listing' | mail obst-listserv@fzi.de
  821. you will get a directory listing from our ftp server.
  822.  
  823. OBST3-4 is a major release with a new meta schema interface
  824. that enables schema modifications. A graphical schema browser
  825. (USE) based on tclOBST is now also available. Please note that this
  826. new tool has not yet been tested outside the FZI and that it
  827. is currently not part of the OBST core cdistribution.
  828.  
  829. Beside bug fixes and performance improvements, we have added support
  830. for IBM AIX and FreeBSD and improved the installation on LINUX PCs.
  831.  
  832. We would like to thank all OBST users who have helped us by testing a 
  833. beta version of OBST, most notably:
  834.   Naresh Sharma (N.Sharma@LR.TUDelft.NL)
  835.   Michael Reifenberger (root@rz-wb.fh-sw.de)
  836.   Hans-Ulrich Kobialka (kobi@borneo.gmd.de) 
  837.   Jean Safar (jsafar@lehman.com)
  838.   Gabor Karsai (gabor@vuse.vanderbilt.edu)
  839.   Stefan Bohm (bohm@math.uni-muenster.de)
  840.  
  841. The installation of OBST requires a C++ compiler
  842. (GNU g++ 2.3.3/2.4.5/2.5.8, or AT&T 2.1/3.01).
  843.  
  844. The OBST graphical tools run under the X-Windows
  845. system (currently X11R4, X11R5 and X11R6). 
  846. Installation has been tested for SunOS4.1.3 and LINUX only.
  847.  
  848. Best regards and happy OBST programming. 
  849.  
  850.    The OBST Team
  851.  
  852. ------------------------------------------------------------------------------
  853. README of OBST3-4
  854. -----------------
  855.  
  856. Version: OBST3-4
  857. Date:    11/4/94
  858.  
  859. The OBject system of STONE --- OBST
  860. -----------------------------------
  861.  
  862. The persistent object management system OBST was developed by
  863. Forschungszentrum Informatik (FZI) as a contribution to the STONE
  864. project (supported by grant no. ITS8902A7 from the BMFT, i.e. the
  865. German Ministry for Research).
  866.  
  867. OBST was originally designed to serve as the common persistent
  868. object store for the tools in software engineering environments.
  869.  
  870.  
  871. Data Model
  872. ---------
  873.  
  874. The OBST data model can be characterized by the following properties:
  875.  
  876.  * Schema definition language syntactically similar to C++
  877.  * Support of multiple inheritance
  878.  * Generic classes
  879.  * Abstract classes and methods
  880.  * Distinction between public, protected, and private methods
  881.  * Redefinition of methods
  882.  * Overloading of methods
  883.  
  884. Schemas and Containers
  885. ----------------------
  886.  
  887. Schemas are compiled by the OBST schema compiler. The compilation
  888. results are instances of classes of the meta schema. From these
  889. instances in a next step interfaces to different programming languages
  890. can be generated. At present the C++ language binding is implemented.
  891.  
  892. Objects are stored in so-called containers. The container an object
  893. belongs to is determined at the time of object creation and fixed
  894. throughout the object's lifetime. Containers are the units of 
  895. clustering, synchronization, and recovery. Objects can be referenced
  896. by other objects across container boundaries.
  897.  
  898. Incremental Loading
  899. -------------------
  900.  
  901. OBST provides a mechanism to incrementally load methods. This enables
  902. programs to deal with objects whose type is defined after the program 
  903. itself has been developed. This is useful in systems that provide for 
  904. inheritance and it supports schema evolution. We used it e.g. for
  905. programs that interpret the object base and call methods of the
  906. found objects (for example the below mentioned browser).
  907.  
  908. Prototype
  909. ---------
  910.  
  911. Since end 1990 the first prototype of OBST is available and is shipped
  912. to interested universities and research institutions. The current
  913. version is publicly available via FTP (see below) since March '92.
  914. There is a mailing list (see below) with >>100 subscribers.
  915.  
  916. The system comes with the schema compiler, a library of predefined
  917. classes (like Set<Entity>, List<Entity>, String, ...), a graphical
  918. object browser (more a shell than a browser), a graphical schema
  919. designer (USE), the structurer and flattener (STF), tclOBST,
  920. and all manuals.
  921. For USE, STF and tclOBST see below.
  922.  
  923. Schema Evolution Support Environment (USE)
  924. ------------------------------------------
  925.  
  926. This environment consists of a graphical schema designer built with
  927. tclOBST (see below). It can be used to inspect existing class hierarchies
  928. and to modify these hierarchies; it allows the addition of new classes
  929. as well as the modification of existing ones.
  930.  
  931. Structurer and Flattener (STF)
  932. ------------------------------
  933.  
  934. This is a tool to build objects from bytestrings and flatten objects
  935. down to bytestrings. It is intended to be used when coupling UNIX
  936. tools to the object management system. The user defines a grammar that
  937. describes her objects. Afterwards, the structurer parses an ascii 
  938. text according to the given grammar and creates an OBST object
  939. structure that represents the corresponding parse tree.
  940. The flattener does the inverse transformation, that means it generates
  941. an ascii text from a given OBST object structure according to the given
  942. grammar.
  943.  
  944. tclOBST
  945. -------
  946.  
  947. tclOBST is a library which provides an embedding of OBST into the
  948. interactive tool command language tcl, developed by John Ousterhout
  949. at the University of Berkeley.
  950. Based on the standard tcl shells, which are also comprised in the
  951. tclOBST distribution, tclOBST offers interactive access to the complete
  952. functionality modelled by OBST schemata.
  953.  
  954.  
  955. System Requirements
  956. -------------------
  957.  
  958. For the prototype's installation a C++ compiler
  959. (GNU g++ 2.3.3/2.4.5/2.5.7 or AT&T 2.0/2.1/3.01) and the
  960. X-Windows system (currently X11R4 or X11R5) for the graphical tools
  961. are required.
  962. Installation is well-tried on SUN Sparc stations and should be no
  963. problem on other UNIX machines, too. You can find a more detailed
  964. description of the supported platforms in the README.install.OBST*.
  965.  
  966. --------------------------------------------------------------------
  967.  
  968. For more information please mail to:
  969.  
  970.                 Forschungszentrum Informatik (FZI)
  971.                        OBST Projekt
  972.                  Haid-und-Neu-Strasse 10-14
  973.                      D-76131 Karlsruhe
  974.                           Germany
  975.  
  976. or email to:  obst@fzi.de
  977.  
  978. Phone:        ++49-721-9654-701
  979. Fax:          ++49-721-9654-709
  980. Teletex:      721 190 fziKA
  981.  
  982. The OBST system is available via anonymous FTP from
  983. ftp.fzi.de [141.21.4.3] and some mirror servers.
  984.  
  985. The system as well as some overview papers, documentation
  986. (User's Guide, Language Reference Manual, Tutorial, ...),
  987. and lots of manual pages can be found in the directory /pub/OBST.
  988.  
  989. There are mailing lists for announcing OBST enhancements,
  990. new versions, porting hints, etc. as well as for exchanging experiences
  991. with other OBST users.
  992.  
  993. Send a mail with content 'LONGINDEX' to obst-listserv@fzi.de to learn about
  994. the mailing lists which are currently installed:
  995.     echo LONGINDEX | mail obst-listserv@fzi.de
  996.  
  997. The mailing lists are maintained by an automatic list processor.
  998. Use 'HELP' to learn about the commands understood by this processor:
  999.     echo HELP | mail obst-listserv@fzi.de
  1000.  
  1001. Bug reports should contain a small example program with which the
  1002. bug can be reproduced, or at least a detailed description of the
  1003. observed phenomenon. They should also mention:
  1004.      o OBST version 
  1005.      o configuration parameters for your OBST version
  1006.        (from file config.status)
  1007.      o kind and version of C++ compiler 
  1008.      o machine
  1009.      o operating system
  1010.  
  1011. Besides bug reports we are strongly interested in all experiences
  1012. our users make with OBST (e.g. sufficiency of data model, performance,
  1013. ...) and in our users' application areas and the applications as
  1014. well. So, please don't hesitate to send us a short note.
  1015.  
  1016. Best regards and happy OBST programming.
  1017.  
  1018.    The OBST Team,
  1019.  
  1020.     Boris Boesler, Dirk Eichberg, Frank Fock, Axel Freyberg,
  1021.     Michael Gravenhorst, Ingolf Mertens, Michael Pergande, Christian Popp,
  1022.     Bernhard Schiefer, Dietmar Theobald, Axel Uhl, Walter Zimmer
  1023.  
  1024. ---
  1025.  
  1026. BTW "Obst" is the German word for "fruit",
  1027.     so have a fruitful time with OBST!
  1028.  
  1029.  
  1030. > Ode
  1031.  
  1032.                                  Ode 2.0
  1033.                        An Object-Oriented Database
  1034.  
  1035.        C++ Compatible, Fast Queries, Complex Application Modeling,
  1036.        Multimedia Support, and more
  1037.  
  1038. See APPENDIX E, Databases, for description.
  1039. Note: Ode version 3.0 is now available.
  1040.  
  1041.  
  1042. > Oggetto, University of Lancaster, UK.
  1043.  
  1044. Developed at the University of Lancaster, UK.  Summary NYI.
  1045.  
  1046. "Oggetto: An Object Oriented Database Layered on a Triple Store",
  1047. J.A. Mariani, The Computer Journal, V35, No 2, pp108-118, April 1992.
  1048.  
  1049.  
  1050. > ORION (Now marketed as ITASCA)
  1051.  
  1052. ORION was a prototype OODBMS developed at MCC, an American consortium by Won
  1053. Kim and his group.  Won Kim has left MCC and formed a new company, UniSQL, in
  1054. Austin, with a new product of the same name.
  1055.  
  1056. See also entry under "ITASCA".
  1057.  
  1058. REFERENCES:
  1059.  
  1060. I have found nearly a dozen papers published by the ORION folks.
  1061. Overviews at various stages in its development and commercialization
  1062. can be found in:
  1063.  
  1064. [KBGW91] Won Kim, N. Ballou, J.F. Garza, and D.; Woelk. A
  1065.          distributed object-oriented database system supporting
  1066.          shared and private databases. ACM Transactions on
  1067.          Information Systems, 9(1):31--51, January 1991.
  1068.  
  1069. [KGBW90] W. Kim, J.F. Garza, N. Ballou, and D. Woelk.
  1070.          Architecture of the orion next-generation database
  1071.          system. IEEE Transactions on Knowledge and Data
  1072.          Engineering, 2(1):109--24, March 1990.
  1073.  
  1074. [KBCG89] Won Kim, Nat Ballou, Hong-Tai Chou, and Darrell Garza,
  1075.          Jorge F. Woelk. Features of the ORION object-oriented
  1076.          database system. In Won. Kim and Frederick H.
  1077.          Lochovsky, editors, Object-Oriented Concepts, Databases
  1078.          and Applications, chapter 11. Addison-Wesley, Reading,
  1079.          MA, 1989.
  1080.  
  1081. [KBC+88] Won Kim, N. Ballou, Hong-Tai Chou, J.F. Garza,
  1082.          D. Woelk, and J. Banerjee. Integrating an
  1083.          object-oriented programming system with a database
  1084.          system. In Proceedings of the ACM Conference on
  1085.          Objected-Oriented Programming:  Systems, Languages and
  1086.          Applications (OOPSLA), pages 142--152, San Diego, CA,
  1087.          September 1988. Published as ACM SIGPLAN Notices
  1088.          23(11).
  1089.          [Pointers to the previous papers documenting each of the
  1090.           advanced features listed above are cited therein.]
  1091.  
  1092.  
  1093. The paper most relevant to the issue of schema evolution is the
  1094. following:
  1095.  
  1096. [BKKK87] J. Banerjee, W. Kim, H-J. Kim, and H.F. Korth.
  1097.          Semantics and implementation of schema evolution in
  1098.          object-oriented databases. In U. Dayal and I. Traiger,
  1099.          editors, Proceedings of the SIGMOD International
  1100.          Conference on Management of Data, San Francisco, CA,
  1101.          May 1987.
  1102.  
  1103.  
  1104. You might also like to look at Kim's book, which provides a good
  1105. introduction to OODBMS, while focusing on the ORION work:
  1106.  
  1107. [Kim90]  Won Kim. Introduction to Object-Oriented Databases.
  1108.          Computer Systems. MIT Press, Cambridge, MA, 1990.
  1109.  
  1110.  
  1111. > OTGen (Carnegie Mellon University/UMass Amherst)
  1112.  
  1113. OTGen is a design for a system to support schema evolution in
  1114. object-oriented databases.  The chief contribution of OTGen is support
  1115. for programmer extensibility of transformation functions to allow a
  1116. system to support a wide range of schema changes, not just those that
  1117. can be easily automated.  While OTGen was never implemented, it is
  1118. based on the implementation of TransformGen, a system to support the
  1119. evolution of the specialized databases used by Gandalf programming
  1120. environments.  For more information on OTGen and TransformGen, please
  1121. see: 
  1122.  
  1123. Barbara Staudt Lerner and A. Nico Habermann, "Beyond Schema Evolution
  1124.     to Database Reorganization", in Proceedings of the Joint ACM 
  1125.     OOPSLA/ECOOP '90 Conference on Object-Oriented Programming:
  1126.     Systems, Languages, and Applications, Ottawa, Canada, October
  1127.     1990, 67-76. 
  1128.  
  1129. Barbara Staudt, Charles Krueger, and David Garlan, TransformGen:
  1130.     Automating the Maintenance of Structure-Oriented Environments, 
  1131.     Computer Science Department Carnegie-Mellon University, Technical 
  1132.     Report CMU-CS-88-186, November 1988.
  1133.  
  1134. David Garlan, Charles W. Krueger, and Barbara J. Staudt, "A Structural
  1135.     Approach to the Maintenance of Structure-Oriented Environments",
  1136.     in Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering
  1137.     Symposium on Practical Software Development Environments, Palo
  1138.     Alto, California, December 1986, 160-170.
  1139.  
  1140. Contact:
  1141. Barbara Lerner
  1142. blerner@cs.umass.edu
  1143.  
  1144.  
  1145. > VODAK
  1146.  
  1147. Research in the framework of VODAK focuses on an extensible data
  1148. model and database programming language, an advanced transaction
  1149. model, object-oriented query language, and support for multimedia data.
  1150.  
  1151. The VODAK Data Model Language VML
  1152.  
  1153. Usually database models lack mechanisms for extending them with
  1154. additional modeling primitives. This limitation does not allow the
  1155. adaptation of the models for specific application needs, e.g. database
  1156. integration, multimedia document handling, hypertext modeling, etc.
  1157.  
  1158. The VODAK Model Language VML  homogeneously integrates the concept of
  1159. metaclasses and the separation of types and classes with other
  1160. object-oriented concepts such as properties, methods, inheritance, and
  1161. object identity. Complex nested data structures can be defined using
  1162. the set, array, tuple, and dictionary type constructors. VML supports
  1163. its own programming language for implementing methods, specifying
  1164. transactions and an ad hoc query language.
  1165.  
  1166. In VML classes are used to organize a set of objects corresponding to
  1167. real world entities and relationships between them. Object types define
  1168. the structure of objects and the operations defined on these
  1169. structures.  They are associated with classes in order to determine the
  1170. structure and behavior of the class' instances. Metaclasses are first
  1171. class objects whose instances are classes. Metaclasses are associated
  1172. with three object types: an (optional) own-type extending their own
  1173. behavior, an instance-type specifying the behavior of their instances
  1174. (which are classes), and an  instance-instance-type specifying the
  1175. behavior of the instances of their instances.  Metaclasses can be
  1176. organized in an instantiation hierarchy of arbitrary depth.
  1177.  
  1178. This approach leads to an open, adaptable data model which provides for
  1179. the specification of additional modeling primitives at a meta layer of
  1180. the database schema. The concept of metaclasses and the separation of
  1181. classes and types allow to determine the structure and behavior of
  1182. objects and the individual inheritance behavior via semantic
  1183. relationships between arbitrary objects already at the meta layer
  1184. independently from the specifications given at the application layer
  1185. for the application specific classes.
  1186.  
  1187.  
  1188. The VODAK Transaction Model
  1189.  
  1190. In VODAK, we focus on two specific problems of transaction management.
  1191.  
  1192. 1. Operations to read and edit (hyper)documents are typically complex,
  1193. interactive and of long duration. A high degree of concurrency is
  1194. required to reduce the number and length of times a transaction is
  1195. blocked.
  1196.  
  1197. 2. A publication environment has to handle existing database systems
  1198. for using and modifying remote information and documents.  Transaction
  1199. managers of existing systems, i.e. concurrency control and recovery,
  1200. have to be integrated in a transparent way utilizing the functionality
  1201. of existing managers.
  1202.  
  1203. Our transaction model is based on open nested transactions. Compared to
  1204. conventional flat transactions, nested transactions allow more
  1205. concurrency and are more flexible for recovery.  A nested transaction
  1206. is a tree-like structure, dynamically built up by the call of
  1207. subtransactions until a bottom implementation level is encountered.
  1208.  
  1209. We extended the open nested model from a fixed calling hierarchy of
  1210. operations in a layered system (multi-level transactions) to an
  1211. arbitrary calling hierarchy of operations in an object-oriented system.
  1212. Commutativity of operations is applied to system defined VODAK methods,
  1213. and to methods of user defined object types.  For the second type of
  1214. operations, we developed a framework to specify commutativity and
  1215. inverse operations in VML.
  1216.  
  1217. Query Processing
  1218.  
  1219. Although nearly all object-oriented data models proposed so far include
  1220. behavioral aspects, most object-oriented query languages, algebras and
  1221. query optimization strategies simply adapt relational concepts since
  1222. they focus on the complex structures of objects and neglect the
  1223. behavior. We claim that this approach is not sufficient since it does
  1224. not reflect the much richer semantics methods can carry which have to
  1225. be taken into account for really efficient query processing. The quite
  1226. straightforward approach we consider is to integrate methods in an
  1227. algebraic framework for query processing and to make there partial
  1228. knowledge about methods available in the form of equivalences. We
  1229. integrate algebraic set operators with methods defined in database
  1230. schemas within an object-oriented data model. We investigate the impact
  1231. on the architecture of the query processor when the algebra becomes an
  1232. extendible component in query processing.
  1233.  
  1234. Multimedia Support
  1235.  
  1236. The V3 Video Server was built as a demonstration showing a multimedia
  1237. application developed on top of the VODAK database management system.
  1238. The V3 Video Server allows a user to interactively store, retrieve,
  1239. manipulate, and present analog and short digital video clips. A video
  1240. clip consists of a sequence of pictures and corresponding sound.
  1241. Several attributes like author, title, and a set of keywords are
  1242. annotated.
  1243.  
  1244. In the future, the VODAK DBMS will be enhanced with new built-in
  1245. functionality for multimedia datatypes. Therefore, existing components
  1246. of VODAK must be changed and new ones must be added to support time
  1247. dependencies, high data volumes, and user interaction.
  1248.  
  1249. Query Processing
  1250.  
  1251. Although nearly all object-oriented data models proposed so far include
  1252. behavioral aspects, most object-oriented query languages, algebras and
  1253. query optimization strategies simply adapt relational concepts since
  1254. they focus on the complex structures of objects and neglect the
  1255. behavior. We claim that this approach is not sufficient since it does
  1256. not reflect the much richer semantics methods can carry which have to
  1257. be taken into account for really efficient query processing. The quite
  1258. straightforward approach we consider is to integrate methods in an
  1259. algebraic framework for query processing and to make there partial
  1260. knowledge about methods available in the form of equivalences. We
  1261. integrate algebraic set operators with methods defined in database
  1262. schemas within an object-oriented data model. We investigate the impact
  1263. on the architecture of the query processor when the algebra becomes an
  1264. extendible component in query processing.
  1265.  
  1266. The VODAK Prototype
  1267.  
  1268. The system architecture consists of a central database environment and
  1269. several external database environments to which the user wants to have
  1270. integrated access. Each of these environments consists of an object
  1271. manager, a message handler, a transaction manager, and a communication
  1272. manager. In addition to these components an external database
  1273. environment includes a database interface module which realizes the
  1274. access to an external database system.
  1275.  
  1276. The DBMS components are currently built on top of DAMOKLES and will be
  1277. in the near future on top of ObjectStore.
  1278.  
  1279. A first version of a C++ based prototype of VODAK is available for Sun
  1280. Sparc Stations under certain conditions.  It implements all the
  1281. features specified in including e.g. metaclasses, transactions, and
  1282. remote message execution.
  1283.  
  1284. References
  1285.  
  1286. P. Muth, T. Rakow, W. Klas, E. Neuhold:  A Transaction Model for an
  1287. Open Publication Environment.  A. K. Elmagarmid (Ed.): Database
  1288. Transaction Models for Advanced Applications. Morgan Kaufmann
  1289. Publishers, San Mateo, Calif., 1992.
  1290.  
  1291. Wolfgang Klas, Karl Aberer, Erich Neuhold Object-Oriented Modeling for
  1292. Hypermedia Systems using the VODAK Modeling Language (VML) to appear
  1293. in: Object-Oriented Database Management  Systems, NATO ASI Series,
  1294. Springer Verlag Berlin Heidelberg, August 1993.
  1295.  
  1296. Karl Aberer, Gisela Fischer Object-Oriented Query Processing: The
  1297. Impact of Methods on Language, Architecture and Optimization
  1298. Arbeitspapiere der GMD No. 763, Sankt Augustin, July 1993.
  1299.  
  1300. T.C. Rakow, P. Muth The V3 Video Server: Managing Analog and Digital
  1301. Video Clips, Sigmod 93, Washington, DC.
  1302.  
  1303. For further information contact
  1304.  
  1305. {aberer,muth,rakow,klas}@darmstadt.gmd.de
  1306.  
  1307.   GMD-IPSI                                             
  1308.   Dolivostr. 15                                                           
  1309.   D-64293 Darmstadt
  1310.   GERMANY    
  1311.                                     
  1312.   FAX: +49-6151-869 966   
  1313.  
  1314.  
  1315. Commercial Systems
  1316. __________________
  1317.  
  1318. > ArtBASE  (Object-Oriented Data Model)
  1319.  
  1320. by:     ArtInAppleS Ltd.
  1321.         Kremelska 13
  1322.         845 03 Bratislava
  1323.         SLOVAKIA
  1324.         Phone: x42-7-362-889
  1325.         fax:   x42-7-777 779
  1326.         EMail: artbase.support@artinapples.cs
  1327.  
  1328. Distributor for Germany:
  1329.         ARS NOVA Software GmbH
  1330.         Stettener Strasse 32/3
  1331.         73732 Esslingen a.N.
  1332.         Germany
  1333.         Phone: x49-711 3704001
  1334.         Fax:   x49-711 3704001
  1335.         EMail: info@arsnova.stgt.sub.org
  1336.  
  1337. Languages: Objectworks\Smalltalk by ParcPlace Systems, Inc.
  1338.  
  1339. Platforms: Unix, PC Windows, Macintosh
  1340.  
  1341. Features:
  1342. - Fully implemented in Objectworks\Smalltalk
  1343.   (ArtBASE is delivered with source code)
  1344.  
  1345. - ArtBASE extents Smalltalk of persistency. Persistent objects are handled the
  1346.   same way as transient objects.
  1347.  
  1348. - Optimistic and pessimistic concurrency control.
  1349.  
  1350. - Transactions, including long lived transactions
  1351.  
  1352. - User concept with access restrictions
  1353.  
  1354. - storing of classes and methods in the database - entire applications 
  1355.   may be stored in an ArtBASE database, including the data AND the 
  1356.   application classes
  1357.  
  1358. - Currently, a single user version is available. The Distributed Multi User Server Version
  1359.   will be presented at the OOPSLA'93 at Washington D.C. in September 1993 for Unix
  1360.   environments and PCs.
  1361.  
  1362. - Existing applications can be turned to database applications very easily using ArtBASE
  1363.  
  1364.  
  1365. > EasyDB (Objective Systems, Sweden)
  1366.  
  1367. EasyDB features a (programming language independent) Data Definition
  1368. Language (DDL) for the definition of schemas.  It relies on the
  1369. Entity-Attribute-Relationship model.  Data Manipulation Languages
  1370. (DML) include a Navigational Query language (NQL) embedded in a host
  1371. language (C available now, Ada in January '93), and a generic C++
  1372. class library.
  1373.  
  1374. On Schema Evolution (from original survey):
  1375. The schema may be freely extended with new items (types, domains,
  1376. attributes, entities, relationships etc.). Deletion of items is not
  1377. allowed.
  1378.  
  1379. Data created with an older schema may co-exist with newer data. Old
  1380. applications need not be recompiled when the schema is updated.
  1381. Attempts by newer applications to access `older' data in an
  1382. inconsistent way are detected and reported via an exception handling
  1383. system.
  1384.  
  1385. [Tomas Lundstrom <tomas@os.se>]
  1386.  
  1387. Objective Systems SF AB (Ericsson)
  1388. Box 1128
  1389. S-164 22 Kista, Sweden
  1390. tel : +46-8-703-4591
  1391. fax : +46-8-750-8056
  1392. contact: Jaan Habma, jaan@os.se
  1393.  
  1394.  
  1395. > GemStone (Servio)
  1396.  
  1397. First introduced in 1987, Servio's GemStone is the oldest commercial ODBMS
  1398. available today. GemStone is particularly well suited for use in complex
  1399. multi-user, multi-platform client/server applications. It supports
  1400. concurrent access from multiple external languages, including Smalltalk-80,
  1401. Smalltalk/V, C++ and C. GemStone also provides a dialect of Smalltalk as an
  1402. internal DML, which can execute methods or entire applications in the
  1403. database.
  1404.  
  1405. Servio also offers GeODE (GemStone Object Development Environment), an
  1406. object database application development environment which allows developers
  1407. to build complete object applications visually, without writing code. With
  1408. GeODE's visual programming tools, programming an application is a matter of
  1409. wiring together graphical representations of encapsulated code blocks. A
  1410. simple extension mechanism promotes the re-use of code, thereby increasing
  1411. the speed of program development. Also, association of application user
  1412. interface elements with database objects is established through simple
  1413. graphical tools. GeODE applications are stored and run in the GemStone
  1414. database, and so are both self-porting and network-aware, and can be
  1415. accessed externally from any of the GemStone language interfaces. Because
  1416. of GemStone's network architecture, Geode applications can operate easily
  1417. in a client/server environment.
  1418.  
  1419.  
  1420.  ==============================================================================
  1421.  
  1422. GEMSTONE
  1423.  
  1424. GemStone is a highly scalable client-multiserver database for commercial
  1425. applications. GemStone's features include:
  1426.  
  1427. o  Active Database -- GemStone allows database application developers to
  1428.    write methods which are stored and executed directly in the database.
  1429.    These methods can be accessed either internally, or from external client
  1430.    applications. This can significantly reduce network traffic and allow
  1431.    applications to take advantage of the superior compute power of the
  1432.    server. This also eliminates the need to rebuild and re-deploy
  1433.    applications whenever application or business processing rules change.
  1434.    This in turn allows for centralized code development and management,
  1435.    architecture-independent code that ports itself to new platforms,
  1436.    reduced network usage, and true client/server applications that share
  1437.    compute load between client and server machines.
  1438.  
  1439. o  Concurrent Support for Multiple Languages -- GemStone provides
  1440.    concurrent support for applications developed in Smalltalk, C++, C or
  1441.    GeODE. All applications, regardless of language, can have simultaneous
  1442.    access to the same database objects.
  1443.  
  1444. o  Flexible multi-user transaction control -- Multiple users can
  1445.    operate in the database simultaneously, with a variety of transaction
  1446.    control modes available.
  1447.  
  1448. o  Object-level security -- Authorization control can be applied to any
  1449.    object in the database, allowing for fine tuning of object security.
  1450.  
  1451. o  Dynamic schema and object evolution -- GemStone supports schema
  1452.    modification through class versioning and allows full migration of
  1453.    objects between versions of their classes with a simple message send.
  1454.    Migration is fully customizable and is undoable.
  1455.  
  1456. o  Production Services -- GemStone delivers the full suite of features
  1457.    required in any production-ready networked database including online
  1458.    backup, rapid recovery, referential integrity, sophisticated concurrency
  1459.    control, and event signals and notifiers.
  1460.  
  1461. o  Scalability -- In a recent independent benchmark, GemStone scaled to
  1462.    support more than 1,000 simultaneous log-ins and 100 concurrent active
  1463.    users on a mid-sized SMP server.
  1464.  
  1465. o  Legacy Gateways -- GemStone incorporates gateways or data bridges
  1466.    that allow object applications to integrate legacy data, whether in SQL,
  1467.    IMS, VASM or other formats. The level of integration between GemStone
  1468.    and legacy data and applications can range from simple query access to
  1469.    extensive read-write interoperability.
  1470.  
  1471.  
  1472.  ==============================================================================
  1473.  
  1474. GEODE
  1475.  
  1476. GeODE is a comprehensive environment for rapidly designing, building and
  1477. deploying production-quality commercial object applications. Its design
  1478. promotes code reuse in a team programming environment for increased
  1479. productivity. GeODE consists of six main elements:
  1480.  
  1481. o  Visual Application Manager -- Provides centralized management
  1482.    of each application and its component parts, and a namespace for
  1483.    addressing known objects.
  1484.  
  1485. o  Visual Schema Designer -- Allows the development of database schema
  1486.    visually, making the process more interactive and intuitive than with
  1487.    object-oriented programming languages. It also provides analysis tools
  1488.    for examining an existing schema.
  1489.  
  1490. o  Visual Forms Designer -- The Forms Designer reads GemStone class
  1491.    definitions and an associated data dictionary to automatically create
  1492.    default forms suitable for simple data entry. These forms can be rapidly
  1493.    customized, using a wide selection of user interface components and
  1494.    field types, which include image and sound support, and a large set of
  1495.    form design aids. The list of field types can be extended interactively.
  1496.  
  1497.